CPU 모니터링과 튜닝

CPU 병목현상을 제거하고 퍼포먼스 높이기

문서 옵션

JavaScript가 필요한 문서 옵션은 디스플레이되지않습니다.

이 페이지를 이메일로 보내기

'); // :badtag -->

이 페이지를 이메일로 보내기

제안 및 의견

피드백

난이도 : 초급

Wayne Huang, 컨설턴트, IBM
Lee Cheng, 컨설턴트, IBM
Matthew Accapadi, 소프트웨어 엔지니어, IBM
Nam Keung, 프로그래머, IBM

2002 년 3 월 01 일
2005 년 7 월 28 일 수정

표준 AIX® 툴을 활용하여 CPU 병목현상을 발견하는 방법을 배워보자. IBM 퍼포먼스 전문가들이 이 툴에서 생성된 리포트들을 해석하여 퍼포먼스를 향상시키는 방법을 설명한다.

머리말

AIX 5L™ Version 5.3은 최신 버전의 AIX® 운영 체계로서 eServer™ 시스템 상에서 동시 멀티 쓰레딩(SMT)을 통해 높은 쓰루풋과 퍼포먼스를 보인다. AIX 5L Version 5.3으로 서버 활용도를 높이고 효율적인 관리를 위해 워크로드를 강화할 수 있다.

컴퓨팅 역사와 OS를 공부하다 보면, 컴퓨터 과학자들이 CPU 스케줄링 정책들을 개발해왔다는 것을 알 수 있다. FIFO(First-in, first-out), SJF(shortest job first), 라운드 로빈(round robin) 등이 바로 그러한 예이다. 이 모든 스케줄링 정책들은 중요하다. 하나의 정책이 모든 애플리케이션에 다 맞는 것이 아니기 때문이다. 특정 워크로드에서 몇몇 애플리케이션들은 기본 스케줄링 정책으로도 잘 운용된다. 하지만 워크로드가 다양하다면 스케줄링 정책 조정이 필요하다.

주: 이 글은 AIX 5.3 릴리스 이후 업데이트 되었다. 고급 가상화는 이 글에서 논의되지 않는다. AIX 5L Version 5.3의 특징, 툴, 기능을 중심으로 설명한다.

위로

SMT란 무엇인가?

SMT는 한 개 이상의 쓰레드에서 명령어를 동시에 디스패치하는 물리적 프로세서의 기능이다. AIX 5L Version 5.3에서는 하나의 물리적 프로세서로 만들어진 전용 파티션이 논리적 투웨이(two-way)로 설정된다. 두 개의 하드웨어 쓰레드는 하나의 물리적 프로세서에서 동시에 실행될 수 있다. SMT는 전체 쓰루풋이 개별 쓰레드의 쓰루풋 보다 중요할 경우에 좋은 선택이 된다. 예를 들어, 웹 서버와 데이터베이스 서버는 SMT를 위한 좋은 후보이다.

프로세서와 애트리뷰트 정보 보기

Listing 1은 SMT 실행 모습이다.

Listing 1. SMT

# smtctlThis system is SMT capable.SMT is currently enabled.SMT threads are bound to the same physical processor.Proc0 has 2 SMT threadsBind processor 0 is bound with proc0Bind processor 2 is bound with proc0Proc2 has 2 SMT threadsBind processor 1 is bound with proc2Bind processor 3 is bound with proc2# lsattr -El proc0frequency   1656376000     Processor Speed       Falsesmt_enabled true           Processor SMT enabled Falsesmt_threads 2              Processor SMT threads Falsestate       enable         Processor state       Falsetype        PowerPC_POWER5 Processor type        False

smtctl 명령어는 권한이 있는 사용자와 애플리케이션이 SMT 지원으로 프로세서의 사용을 제어할 수 있도록 한다. 이 명령어를 사용하여 SMT를 켜거나 끌 수 있다. smtctl 명령어 신택스는 다음과 같다.

smtctl [-m off | on [ -w boot | now] ]

공유 프로세서란 무엇인가?

공유 프로세서는 타임슬라이스 기반으로 파티션에 할당된 물리적 프로세서이다. 공유 프로세서 풀(pool)에서 물리적 프로세서를 사용하여 공유 프로세서 풀을 사용하는 파티션의 실행 필요를 채울 수 있다. eServer p5 시스템에는 공유 파티션과 전용 파티션이 혼합될 수 있다. 파티션은 모두 공유이거나 모두 전용이어야 하고 동적 LPAR(DLPAR) 명령어를 사용하여 이들 둘 사이를 변경할 수 없다.

프로세싱 단위

파티션을 설정한 후에 프로세싱 단위를 할당할 수 있다. 하나의 파티션은 최소한 프로세서의 1/10을 가져야 한다. 요구사항이 충족된 후에 프로세서의 1/100의 세분성으로 프로세싱 단위를 설정할 수 있다.

각 파티션은 10밀리초(ms) 타임슬라이스에 대해 실행 디스패치 시간의 백분율로 설정된다.

0.2 프로세싱 단위를 가진 파티션은 각 타임슬라이스 동안 20 퍼센트의 용량을 부여 받는다.
1.8 프로세싱 단위를 가진 파티션은 각 10ms 타임슬라이스(다중 프로세서 사용)에 18ms 프로세싱 시간으로 할당된다.

사용되지 않은 사이클은 축적되지 않는다. 파티션이 할당된 프로세싱 용량을 사용하지 않으면 초과 프로세싱 시간이 공유 프로세싱 풀에 양도된다.

공유 프로세서를 가진 파티션은 제한(capped)이거나 무제한(uncapped)이다. 제한 파티션은 한정된 용량으로 할당된다. 파티션이 추가(총 프로세싱 단위 보다 큰) CPU 사이클을 필요로 하면 공유 풀에서 사용되지 않은 용량을 사용할 수 있다.

위로

스케줄링 알고리즘

AIX 5는 다음과 같은 스케줄링 정책을 구현한다. FIFO, 라운드 로빈, FAIR 라운드 로빈. FIFO 정책은 세 가지 다른 구현(FIFO, FIFO2, FIFO3)들을 갖고 있다. AIX에서 라운드 로빈 정책의 이름은 SCHED_RR 이고 FAIR 라운드 로빈은 SCHED_OTHER 이다. 다음 섹션에서 자세하게 설명하겠다.

스케줄링 정책은 할당과 관리 방법(응답 시간과 쓰루풋)에 따라 시스템 퍼포먼스에 중대한 영향을 미칠 수 있다. 예를 들어, FIFO는 많은 CPU를 사용하는 작업에는 좋은 선택이지만, 라인에서 대기하는 다른 모든 작업들을 방해할 수 있다. 기본적인 라운드 로빈은 시간 공유 방식으로 "타임슬라이스(timeslice)" 또는 "할당량(quantum)"을 준다. 결과적으로 I/O 중심의 태스크에서 차별되는 경향이 있다. 왜냐하면 이러한 태스크들은 I/0 대기 때문에 CPU를 자발적으로 포기하기 때문이다. FAIR 라운드 로빈은 "공정하다(fair)" 실행하는 동안 작업은 CPU 시간의 할당량을 축적하기 때문에 스케줄링 우선순위는 변한다. OS는 CPU를 잡고 있는 것을 강등 시켜 I/O 바운드 작업이 공정한 기회를 가져 CPU 리소스를 사용할 수 있도록 한다.

스케줄링에 앞서 두 가지 중요한 개념, nice 값 그리고 AIX 우선순위와 실행 큐(run queue) 구조를 설명하겠다.

nice와 renice 명령어

AIX에는 두 가지 중요한 스케줄링 명령어가 있다. (nice와 renice) AIX의 사용자 작업은 기본적인 우선순위 레벨 40과 디폴트 nice 값 20을 수행한다. 이 두 개의 숫자는 디폴트 우선순위 레벨 60을 형성한다. 이 값은 시스템에서 볼 수 있는 대부분의 작업에 적용된다.

nice명령어(nice -n 10 myjob)로 작업을 시작하면 숫자 10은 delta_NICE가 된다. 이 숫자는 디폴트 20에 추가되어 새로운 nice 값 30을 만든다. AIX에서는 이 숫자가 커질수록 우선순위는 낮아진다. 이 예제를 사용하면 작업은 우선순위 70으로 시작한다. 이것은 디폴트 보다 우선순위에서 10 레벨이 더 뒤쳐진 것이다.

renice 명령어는 이미 시작한 작업에 적용된다. 예를 들어, renice -n 5 -p 2345 명령어는 프로세스 2345가 nice 값 25를 갖게 한다. renice 값은 프로세스의 현재 nice값과 상관 없이 언제나 기본 nice 20에 붙는다.

AIX 우선순위와 실행 큐 구조

쓰레드는 우선순위 범위 0에서 255 까지 실행한다.(이 범위는 AIX 5 이전에는 0에서 127 이다.) 우선순위 0은 가장 높거나 가장 선호되는 것이고 255는 그 반대이다. AIX는 266-레벨 우선순위 큐의 형태로 실행 큐를 관리하여 쓰레드의 256 우선순위 레벨을 효율적으로 지원한다.

AIX는 256-비트 어레이를 구현하여 256 레벨의 큐로 매핑한다. 특정 큐 레벨이 비어있으면 상응하는 비트도 0으로 설정된다. 이 디자인에서는 AIX 스케줄러가 첫 번째의 비어있지 않은 레벨을 빠르게 구분하고 그 레벨에서 첫 번째로 실행 준비가 된 작업을 시작한다. 그림 1의 AIX 실행 큐 구조를 보자.

그림 1. 스케줄러 실행 큐
Scheduler run queue

그림 1에서 스케줄러는 디스패치 준비가 된 모든 쓰레드의 실행 큐를 관리한다. 주어진 우선순위의 모든 디스패치 가능한 쓰레드들은 실행 큐에서 연속적인 위치를 차지한다.

AIX 5L은 각 CPU에 대해 하나의 실행 큐와 글로벌 큐를 구현한다. 예를 들어, eServer pSeries® p590 머신에는 32개의 실행 큐와 한 개의 글로벌 큐가 있다. CPU 당 실행 큐로 인해 쓰레드는 선점 후에 같은 CPU로 돌아갈 더 나은 기회를 갖는다. 이것은 유사성 향상이다. 또한, 실행 큐 구조를 잠그기 위한 CPU들 간 경쟁도 훨씬 줄어들었다. 다중 실행 큐 덕분이다.

하지만 어떤 경우는 다중 실행 큐 구조가 바람직하지 않다. 시스템 환경 변수 RT_GRQ=ON를 반출하면 이것이 실행 가능한 상태가 될 때 쓰레드가 글로벌 실행 큐에 놓일 수 있다. 이것은 인터럽트 중심 쓰레드와 SCHED_OTHER를 실행하는 쓰레드의 퍼포먼스를 높인다. schedo –o fixed_pri_global =1이 AIX 5L Version 5.2 및 이후 버전에서 실행되면 고정된 우선순위를 실행하는 쓰레드들은 글로벌 실행 큐에 놓이게 된다.

로컬 실행 큐의 경우, 이 디스패쳐는 CPU를 사용할 수 있을 때 실행 큐에서 최상의 우선순위 쓰레드를 고른다. 쓰레드가 CPU에서 실행될 때 이것은 CPU의 실행 큐에 머무르게 된다. 그 CPU가 분주할 경우 쓰레드는 또 다른 유휴 CPU로 디스패치 되고 그 CPU의 실행 큐로 할당된다.

FIFO

FIFO 정책이 간단하지만 비 선점(non-preemptive) 특징 때문에 거의 사용되지 않는다. 이 스케줄링 정책을 가진 쓰레드는 다음과 같은 경우를 제외하고는 언제나 완료될 때 까지 실행된다.

sleep() 또는 select() 같이 쓰레드를 수면(sleep)하게 하는 함수를 실행하여 CPU를 자발적으로 포기한다.
리소스 경쟁으로 인해 차단된다.
I/O 완료까지 기다려야 한다.

식품가게의 계산대는 전형적인 FIFO 정책을 사용한다. 단 하나의 체크아웃 레인에(배고픈 상태이다.) 있는데 앞에 있는 사람의 카트에는 물건들이 가득 차 있다. 여러분은 무엇을 할 수 있을까? 할 수 있는 일이 그렇게 많지 않다. 이것은 FIFO 이기 때문에 인내심을 가지고 자신의 차례를 기다려야 한다.

마찬가지로 여러 태스크들이 AIX에서 FIFO를 실행하고 있다면 작업 응답 시간은 심각하게 타격을 받는다. 따라서, FIFO는 AIX에서는 거의 사용되지 않는다. 루트가 소유한 프로세스만이 thread_setsched() 시스템 호출을 통해 스스로를 또는 다른 쓰레드를 FIFO로 설정할 수 있다.

FIFO 정책에는 두 가지 변종들이 있다. 바로 FIFO2와 FIFO3 이다. FIFO2에 따르면 사전 정의된 틱(tick)(affinity_lim ticks로서 schedo -p 명령어로 튜닝 가능하다.)의 수 보다 적은 짧은 시간 동안에만 수면중일 경우에, 쓰레드는 실행 큐의 헤드에 놓여진다. 이로서 쓰레드는 캐시 콘텐트를 재사용 할 좋은 기회를 갖게 된다. FIFO3의 경우, 쓰레드는 실행 가능한 상태가 될 때 언제나 큐의 헤드에 놓이게 된다.

라운드 로빈

잘 알려진 라운드 로빈 스케줄링 정책은 유닉스 보다도 오래되었다. AIX 5L은 256 레벨의 멀티레벨 우선순위 큐의 상단에 라운드 로빈을 구현한다. 주어진 우선순위 레벨에서, 라운드 로빈 쓰레드는 CPU 타임슬라이스와 같은 우선순위를 가진 다른 모든 엔트리들과 공유한다. 쓰레드는 다음과 같은 상황 중 하나가 발생할 때 까지 실행되도록 스케줄링 된다.

CPU를 다른 내어줄 때.
I/O를 위해 블록킹(block) 될 때.
타임슬라이스를 소진할 때.

타임슬라이스가 소진되면 같거나 더 나은 우선순위의 쓰레드가 그 CPU에서 실행될 수 있다면 현재 실행되는 쓰레드는 다음 차례를 위해 큐의 끝에 놓인다. 쓰레드는 깨어있는 더 높은 우선순위 작업 또는 디바이스 인터럽트로 인해 선점될 수 있다. (예를 들어, I/O가 수행된 후).

라운드 로빈 태스크만 보자면, 이렇게 선점된 쓰레드는 큐 레벨의 초반에 놓이게 된다. 왜냐하면 AIX에서는 라운드 로빈 체인의 끝으로 이동하기 전에 라운드 로빈 작업이 전체 타임슬라이스를 갖고 있다는 것을 확인해야 하기 때문이다. 라운드 로빈 쓰레드의 우선순위는 고정되어 시간이 변해도 변경되지 않는다. 이것 때문에 라운드 로빈 태스크의 우선순위가 영속적일 수 있는 것이다. (FAIR 라운드 로빈의 우선순위와는 반대 개념이다.)

라운드 로빈 쓰레드가 특별한 상태를 갖고있기 때문에, 오직 루트(root)만 쓰레드를 설정하여 라운드 로빈 스케줄링 정책으로 이를 실행할 수 있다. 쓰레드에 SCHED_RR을 설정하려면 다음과 같은 애플리케이션 프로그래밍 인터페이스(API)들 중 하나를 사용한다. thread_setsched() 또는 setpri().

SCHED_OTHER

마지막 스케줄링 정책 역시 디폴트이다. 태스크들 사이에서 가장 공정한 정책을 확립하면서 이러한 혁신적인 SCHED_OTHER 알고리즘은 그렇게 혁신적이지 않은 POSIX™ 로 정의된 이름으로 만들어졌다. AIX SCHED_OTHER는 기본적으로는 우선순위-큐 라운드 로빈 디자인이다. 한가지 중요한 차이가 있다. 이 우선순위는 더 이상 고정되지 않는다. 한 태스크가 과도한 CPU 시간을 사용하고 있다면 우선순위 레벨은 강등되어 다른 작업들도 CPU에 액세스 할 기회를 갖도록 한다.

한 태스크가 우선순위 레벨이 너무 낮아서 실행할 기회를 가질 수 없다면 그 우선순위는 높은 레벨로 업그레이드 되어 될 수 있어야 한다. 한 가지 새로운 개념 역시 구현되어서 nice 값의 효과를 강화했다. 태스크가 시작할 때 nice(UNIX nice 값) 이면 시스템은 이것을 언제나 nice로 유지한다. 나중에 설명하겠다.

전통적인 CPU 활용방법

AIX 5.3 이전 또는 SMT를 사용할 수 없을 때, AIX 프로세서는 샘플 기반의 접근 방식을 사용했다.

사용자 프로그램을 실행하면서 소비한 프로세서 시간의 백분율
시스템 코드
디스크 I/O 대기
유휴 시간

AIX는 샘플을 취하기 위해 초당 100개의 인터럽트를 만든다. 각 인터럽트에서 로컬 타이머 틱(10ms)은 타이머 인터럽트에 의해 선점된 현재 실행 쓰레드에 부과된다. 다음의 활용 카테고리들 중 하나가 인터럽트 쓰레드의 상태에 따라 선택된다.

시스템 호출을 사용하는 커널에서 쓰레드가 코드를 실행하면 전체 틱은 프로세스 시스템 시간에 부과된다.
쓰레드가 애플리케이션 코드를 실행했다면 전체 틱은 프로세스 사용자 시간으로 부과된다. 그렇지 않으면, 현재 실행 쓰레드가 OS의 유휴 프로세스이면 틱은 개별 변수로 변경된다. 이 방식의 문제는 틱을 받는 프로세스가 전체 타이머 기간동안 실행되지 않고 타이머가 종료될 때 실행될 수 있다는 점이다. AIX 5.3 SMT를 실행시키면 전통적인 활용 메트릭스는 두 개의 논리적 프로세서 때문에 길을 잃는다.
한 쓰레드가 100 퍼센트 사용 중이면 한 개의 유휴 쓰레드는 50퍼센트 활용 상태가 된다. 하지만 실제로는 한 개의 SMT 쓰레드가 모든 CPU 리소스를 사용한다면, 새로운 Processor Utilization Resource Register- (PURR) 기반 메소드를 사용하여 리포트 된 것처럼 CPU는 100퍼센트 사용중이다.

PURR

AIX 5.3에서는 각 쓰레드에 대한 디스패치 사이클의 수는 PURR라고 하는 새로운 레지스터를 사용하여 측정될 수 있다. 각각의 물리적 프로세서는 두 개의 PURR 레지스터를 갖고 있다.(하나는 각 하드웨어 쓰레드용이다.) PURR는 POWER5 프로세서에서 제공한 새로운 레지스터이고 논리적 프로세서가 사용했던 물리적 프로세싱 시간 단위의 실제 카운트를 제공한다. 모든 퍼포먼스 툴과 API는 이 PURR 값을 사용하여 SMT 시스템의 CPU 활용 메트릭스를 보고한다. 이 레지스터는 특별한 목적을 가진 레지스터이고 POWER™ Hypervisor™에 의해 읽히고 쓰인다. 하지만 이것은 OS에서는 읽기 전용이다. PURR에 대한 하드웨어 증가량은 각 쓰레드에 할당된 디스패치 사이클을 포함하여 각 쓰레드가 프로세서용 리소스를 어떻게 사용하고 있는지에 기반한다. 어떤 명령어도 증가되지 않은 사이클의 경우, 마지막으로 명령어를 디스패치 했던 쓰레드의 PURR가 증가된다. 이 레지스터는 자동으로 진행되기 때문에 OS는 언제나 현재의 최신 값을 얻을 수 있다.

프로세서가 싱글-쓰레드 모드에 있을 때, PURR는 8 개의 모든 프로세스 클럭 사이클 만큼 증가한다. 프로세서가 SMT 모드에 있으면 사이클의 명령어 그룹을 디스패치하는 쓰레드는 그 사이클에서 1/8 만큼 카운터를 증가시킨다. 주어진 사이클에서 그룹 디스패치가 발생하지 않으면 두 개의 쓰레드가 1/16 만큼 PURR를 증가시킨다. 시간 주기 동안 두 개의 PURR 레지스터의 합은 SMT 모드에서 실행될 때 근사치에 가깝지만 타임베이스 틱의 수 보다는 크지 않다.

AIX 5.3 CPU 활용

AIX 5L V5.3에서 샘플 기반 방식 보다는 상태 기반 방식을 사용하는 커널에서 수집되는 새로운 메트릭스가 있다. 상태 기반은 10ms의 설정 시간이 보다는 PURR 증가에 기반한 정보 컬렉션이다. AIX 5.3은 프로세스 어카운팅에 PURR를 사용한다. 전과 같이 인터럽팅된 프로세스에 대해 전체 10ms 클럭 틱을 부과하는 대신 마지막 인터벌 후에 하드웨어 쓰레드에 대해 PURR 델타에 프로세스가 부과된다. 각 인터럽트에서는,

시간이 경과된 PURR는 현재 샘플 기간동안 계산된다.
이 값은 이전에 추가된 고정된 크기의 증가(10ms) 대신, 적절한 사용 목록( user, sys, iowait, idle)에 추가된다.

두 가지 다른 측정 방법이 있다. 쓰레드의 프로세서 시간과 경과된 시간이다. 경과된 시간을 측정하려면 시간 기반 레지스터(TB)가 여전히 사용된다. 논리적 프로세서에 대한 물리적 리소스 활용 메트릭스는,

(delta PURR/delta TB) : 논리적 프로세서가 소비한 물리적 프로세서의 조각을 나타낸다.
(delta PURR/delta TB) * 100 : 논리적 프로세서에 주어진 디스패치 사이클의 백분율을 나타낸다.

CPU 활용 예제

두 개의 쓰레드가 SMT를 실행한 채 한 개의 물리적 프로세서에서 실행된다고 가정해 보자. 한 개의 물리적 CPU에 두 개의 SMT 쓰레드는 바쁘다. 옛날 틱 기반 방식을 사용하여 두 개의 SMT 쓰레드는 100퍼센트 사용 중(busy)인 것으로 리포트 되지만 실제로는 CPU 리소스를 공평하게 공유하고 있는 것이다. 새로운 PURR 기반 방식은 각 SMT 쓰레드를 50퍼센트 사용중인 것으로 나타낼 수 있다는 소리가 된다.

PURR 방식을 사용하면, 각 논리적 프로세서는 이것이 사용했던 물리적 프로세서 리소스들의 비율을 50 퍼센트로 나타낸다. 이는 물리적 프로세서의 리소스들이 두 개의 하드웨어 쓰레드에 똑 같이 분배된 것으로 간주한 것이다.

추가 CPU 활용 메트릭스

다음 메트릭스는 쓰레드당 PURR 메소드를 사용하여 쓰레드의 프로세서 시간을 측정하고 TB 레지스터를 사용하여 경과된 시간을 측정한다.

표 1. 쓰레드당 PURR 메소드

추가 CPU 활용 메트릭스	정보
%sys=(delta PURR in system mode/entitled PURR) * 100 : entitled PURR – (ENT * delta TB)와 ENT는 프로세서 (entitlement/100)의 #에 있는 인타이틀먼트이다.	물리적 CPU 활용 메트릭스는 PURR 기반 샘플과 인타이틀먼트를 사용하여 계산된다.
한 파티션에서 각각의 논리적 프로세서에 대한 (delta PURR/delta TB) 합	인터벌을 통해 소비된 물리적 프로세서.
(PPC/ENT) * 100	인타이틀먼트 소비량 백분율.
(delta PIC/delta TB): PIC는 Pool Idle 카운트이다. 이것은 POWER Hypervisor가 유휴인 곳에서 클럭 틱을 나타낸다.	사용할 수 있는 프로세서(pool)
전통적인 10ms 틱 기반 %sys와 %user의 합	논리적 프로세서 활용도를 통해 더 많은 가상 프로세서들이 파티션에 추가되어야 하는지를 결정할 수 있다.

위로

AIX 5.3 명령어 변경

AIX를 SMT와 함께 실행하면 CPU 정보를 디스플레이 하는 명령어 vmstat, iostat, topas, sar는 전통적인 샘플 기반의 통계가 아닌 PURR 기반의 통계를 디스플레이 한다. SMT 모드에서 추가 정보 칼럼이 디스플레이 된다. ( 표 2)

표 2. SMT 모드

칼럼	설명
pc 또는 physc	파티션에서 소비한 물리적 프로세서
pec 또는 %entc	파티션에서 소비한 양의 백분율

변경을 필요로 했던 또 다른 툴은 trace/trcrpt이고 트레이스 유틸리티에 기반한 여러 다른 툴들이 있다. SMT 환경에서 트레이스는 각 트레이스 후크에 PURR 레지스터 값을 선택적으로 모을 수 있고 trcrpt는 경과된 PURR을 디스플레이 할 수 있다.

표 3은 SMT에 사용할 인자들이다.

표 3. SMT용 인자

인자	설명
trace – r PURR	PURR 레지스터 값을 모은다. 64-비트 커널에서 실행되는 트레이스에만 유효하다.
trcrpt –O PURR=[on\|off]	스크립트에게 타임스탬프와 함께 PURR를 보여줄 것을 명령한다.
netpmon –r PURR	타임베이스(%)와 CPU 계산 대신 PURR 시간을 사용한다. 경과된 시간 계산과는 관련이 없다.
pprof –r PURR	타임베이스(%)와 CPU 계산 대신 PURR 시간을 사용한다. 경과된 시간 계산과는 관련이 없다.
gprof	GPROF는 SMT를 지원하는 새로운 환경 변수이다.
curt –r PURR	PURR 레지스터 사용을 지정하여 CPU 시간을 계산한다.
splat –p	PURR 레지스터 사용을 지정하여 CPU 시간을 계산한다.

위로

쓰레드 우선순위 포뮬라

아래 Listing 2의 포뮬라를 사용하여 쓰레드의 우선순위를 계산할 수 있다. 이것은 nice 값의 기능, CPU 사용 c, 튜닝 팩터 r이다.

위로

AIX가 새로운 우선순위를 계산하는 방법

클럭 타이머 인터럽트는 각 CPU 상에서 10ms 또는 1 틱 마다 발생한다. CPU의 클럭 타이머가 또 다른 CPU의 클럭 타이머와 동시에 시작되지 않도록 이 타이머는 시차를 둔다. CPU 클럭 타이머 인터럽트가 발생하면 쓰레드는 하나씩 증가된 CPU 사용값을 가진다. 최대 120까지 증가한다. 작업이 완전한 10ms 슬라이스에 도달하지 않거나 PR 정책을 실행하지 않으면 시스템 디스패쳐는 실행 큐의 쓰레드 우선순위를 변경하여 다시 시작하도록 한다.

대부분의 사용자 프로세스의 우선순위는 프로세스가 최근에 사용했던 CPU의 총 시간에 따라 변한다. CPU 스케줄러의 우선순위 계산은 schedo, sched_R, sched_D로 설정된 두 개의 매개변수에 기반한다. sched_R과 sched_D 값은 32/1 초이다. 이 스케줄러는 이 포뮬라로 계산하여 최근 CPU 사용에 대한 패널티로서 프로세스의 우선순위 값에 더한다.

CPU penalty = (recently used CPU value of the process) * (r/32)

최근에 사용된 각 프로세스의 CPU 값을 재계산 하는 방법은 다음과 같다.

New recently used CPU value = (old recently used CPU value of the process) * (d/32)

r(sched_R 매개변수)과 d (sched_D 매개변수)는 디폴트 값 16을 갖고 있다.

C를 사용하여 우선순위 패널티를 결정하고 새로운 쓰레드 우선순위를 다시 계산한다. 첫 번째 포뮬라를 사용하면(Listing 2), 기본 우선순위 40, 디폴트 nice 값 20, 비 CPU 부과(C=0)로 새롭게 시작된 사용자 태스크는 우선순위 레벨 60으로 시작한다.

또한, 첫 번째 포뮬라에서 r 값은 패널티 비율 범위를 0에서 32로 결정한다. r 값이 0이라는 것은 CPU에 부과되지 않은 패널티를 의미한다. 이것은 언제나 0이기 때문이다. (C*r/32). r=32 라면, 이것은 CPU에 대해 가장 높은 패널티를 부과한다. CPU 사용에 대한 각 틱(10ms)은 우선순위 레벨이 한 단계 내려간다.

대부분의 경우, r 값은 0과 32 사이에 중간에 놓인다. AIX는 기본적으로 r은 16이다. 두 개의 모든 틱이 한 가지 레벨의 우선순위 패널티가 된다. r 값이 높으면 nice 값의 영향은 덜 중요해 진다. CPU 패널티가 우세하기 때문이다. 반대로, 더 작은 r은 nice 값에 보다 분명한 영향을 끼친다.

이 논의에 따르면 nice 값의 효과는 떨어진다. CPU 부과는 시간별로 증가하고 새로운 우선순위를 결정하는 중요한 요소가 되기 때문이다.

이 포뮬라는 AIX 5L에서는 변경되어 우선순위 레벨을 계산할 때 nice 값의 중요성을 높였다. AIX의 다른 모든 버전들에서 두 개의 새로운 팩터가 도입되었다. x_nice와x_nice_factor ("extra nice"와 "extra nice factor"). (Listing 2)

Listing 2. 쓰레드 우선순위 포뮬라

<Formula 1 : The Basic Formula>Priority = p_nice + (C * r/32)                 (1)<Formula 2 : for AIX 5L>Priority = x_nice + (C * r/32 * x_nice_factor) (2)Where:   p_nice = base_PRIORITY + NICE      base_PRIORITY = 40      NICE = 20 + delta_NICE      (20 is the default nice value)      That is,    P_nice = 60 + delta_NICE   C is the CPU usage charge      The maximum value of C is 120   If NICE <= 20 then x_nice = p_nice   If NICE > 20 then   x_nice = p_nice * 2 - 60 or   x_nice = p_nice + delta_NICE, or         (3)   x_nice = 60 + (2 * delta_NICE)           (3a)   x_nice_factor = (x_nice + 4)/64          (4)   Priority has a maximum value of 255

Formula 2와 Formula 3에서 보듯, x_nice는 증가된 nice 값을 두 배로 불렸다. x_nice_factor는 r 비율을 강화했다. 예를 들어, nice 값 36을 부여하는 초기 nice 16은 새로운 x_nice_factor 1.5가 된다. 이 값은 50 퍼센트 더 높은 CPU 부과 패널티이다.

CPU 사용 줄이기

쓰레드가 실행할 기회가 전혀 없을 정도의 낮은 우선순위도 얻을 수 있다. 이것은 쓰레드의 우선순위 레벨을 뒤로 미루는 메커니즘 없이 Formulas 1과 2 만을 사용할 경우 발생한다.

쓰레드가 SCHED_OTHER로 실행되면 우선순위는 CPU를 위해 강등된다. 실행되지 않고 순서를 기다리면 AIX는 CPU 부과를 약 1초에 한번으로 줄여서 우선순위를 다시 얻으려고 한다. 규칙은 간단하다. CPU로 묶인 작업에는 낮은 우선순위가 할당되어 다른 작업이 실행되도록 하는 것이다. 모든 쓰레드의 CPU 부과량은 초당 한번으로 사전 정의된 팩터에 기반하여 줄어든다.

New Charge C = (Old Charge C) * d / 32              (5)

커널 프로세스 Swapper가 이 작업을 수행한다. 매 초마다 한 번씩 Swapper가 실행되어 이 모든 쓰레드를 감소시키면서 CPU 부과량을 핸들한다. 기본 감소 팩터는 0.5 또는 d=16 이다.

이 방식을 사용하여, CPU 중심의 작업은 CPU 부과량을 축적하고 우선순위 레벨을 낮춘 더 높은 레벨로 진행된다. 반면 I/O 중심의 작업은 우선순위의 범위가 다양하지 않다. 더 적은 CPU 시간을 축적하기 때문이다.

위로

CPU를 다 써버렸나요?

지금까지 AIX 스케줄러에서 워크로드에 우선순위를 부여하는 방식을 알았다. 이제 몇 가지 공용 명령들을 살펴보기로 하자. AIX 스케줄러에서 워크로드를 종료하는 데 시간이 너무 오래 걸리는 것 같거나 워크로드에 충분히 빨리 응답하지 않는 경우엔 vmstat, iostat, sar와 같은 명령들을 수행해 여러분 시스템이 연산위주인지 그 여부를 조사하면 된다.

여기에서는 이와 같은 명령들을 사용할 모든 방법들에 대해 논의하지는 않고 이 방법들을 통해 여러분이 알 수 있는 정보에 대해 중점적으로 얘기하고자 한다. vmstat, iostat 및 sar와 같은 명령에 관한 자세한 내용에 관해선 AIX에 관련된 출판물, 또는 AIX 웹 사이트 http://www-1.ibm.com/servers/eserver/pseries/library/를 참조하라. 필요한 경우엔 화면 아래로 이동해 AIX Version 5L Version 5.3 documentation library를 클릭, AIX 5 출판물을 이용하면 된다.

쓰레드에 관한 우선순위 변경 히스토리

Listing 3에서는 CPU 차지 쓰레드 우선순위를 변경하는 방식에 관해 나와 있다.

Listing 3. CPU 차지 변경 및 쓰레드 우선순위

Base priority is 40Default NICE value is 20, assume task was run using thedefault nice valuep_nice = base_priority + NICE = 40 + 20 = 60Assume r = 2 to slow down the penalty increase (defaultr value is 16)Priority = p_nice + C*r/32 = 60 + C * r / 32Tick 0 P = 60 + 0 * 2 / 32 = 60Tick 1 P = 60 + 1 * 2 / 32 = 60Tick 2 P = 60 + 2 * 2 / 32 = 60….Tick 15 P = 60 + 15 * 2 / 32 = 60Tick 16 P = 60 + 16 * 2 / 32 = 61Tick 17 P = 60 + 17 * 2 / 32 = 61….….Tick 100 P = 60 + 100 * 2 / 32 = 66Tick 100 Swapper decays all CPU usage charges for all threads.New C CPU Charge = (Current CPU Charge) * d / 32Assume d = 16 (the default)For the test thread, new C = 100 * 16 / 32 = 50Tick 101 P = 60 + 51 * 2 / 32 = 63

Listing 4에서는 빠른 또는 느린 우선순위 설정방식에 관해 나와 있다.

Listing 4. 전형적인 연산위주 작업(빠른 우선순위 설정 대 느린 우선순위 설정)의 우선순위 변경

fast.c:main(){for (;;)}slow.c:main() {sleep 80;}

위로

공용 명령

CPU 모니터링 시 vmstat, iostat 및 sar 명령을 종종 사용한다. 여러분은 각 명령에서 만들어내는 리포트 용도 및 의미를 잘 알고 있어야 한다.

vmstat

vmstat 명령은 리포트 당 한 라인 포맷(one-line-per-report)으로 CPU, 디스크 및 메모리 활동을 통한 리소스 활용 개요를 제공한다. Listing 5에서 나오는 샘플 출력은 "vmstat 1 6"을 작동시키는 AIX 5L Version 5.3 system 상에서 발생된다. 시스템 요구대로 이와 같은 리포트는 매초마다 발생한다. 1초 뒤 "Count of six"가 지정되기 때문에 여섯 번째 리포트 후 리포팅은 중지된다. vmstat 명령을 작동시키는 일반적인 방법 가운데는 카운트 매개변수를 생략하는 방법이 있다. 이 경우 여러 리포트를 연속적으로 발생시킨 뒤 vmstat 명령이 종결된다.

한편 avm 및 fre 열을 제외한 상태에서 첫번째 열은 시스템 작동시작 시점서부터 매 초당 나오는 평균 통계 데이터들을, 이후 연속적으로 이어지는 리포트들은 첫번째 리포트 후 1초 동안 수집된 통계 데이터를 포함한다.

AIX 5L Version 5.3에서 vmstat 명령이 시작되는 경우 이 명령을 통해 사용된 물리적 프로세서 개수(pc) 및 Micro-Partitioning™(마이크로 파티셔닝) 및 SMT 환경에서 사용된 인타이틀먼트 비율을 기록한다. 이와 같은 측정 기준들은 Micro-partitioning™ 및 SMT 기준에서만 나타난다.

AIX 5L의 경우에서는 vmstat 명령에 새로운 유용 옵션 "-I"를 부가적으로 추가하는데 이 옵션에서는 주로 미가공(raw) I/O를 종료하는 데 대기하는 쓰레드 수(p 열)와 매 초당 페이지 인/아웃 되는 파일 페이지 수(fi/fo 열)가 나오게 된다.

상기 열에 관한 다음의 내용은 CPU 활용에 관한 유용한 정보를 제공한다. Listing 5에서는 vmstat 1 6 명령에서의 출력에 관해 나와 있다.

Listing 5. p520 시스템에서 나오는 vmstat 16 명령에서의 출력 (두 개의 CPU)

vmstat 1 6 System configuration: lcpu=4 mem=15808MB  kthr   memory     page     faults      cpu -----  -------    ------   --------    ----------- r b avm    fre    re  pi  po  fr  sr  cy  in   sy   cs  us sy id wa 1 1 110996 763741 0   0   0   0    0   0 231   96   91  0  0  99  0 0 0 111002 763734 0   0   0   0    0   0 332 2365  179  0  1  99  0 0 0 111002 763734 0   0   0   0    0   0 330 2283  139  0  5  93  1 0 0 111002 763734 0   0   0   0    0   0 310 2212  153  0  0  99  0 1 0 111002 763734 0   0   0   0    0   0 314 2259  173  0  0  99  0 0 0 111002 763734 0   0   0   0    0   0 321 2261  177  0  1  99  0

그림 2에서는 vmstat -I 1(소프트웨어 설치 시 나옴) 명령에서 나오는 출력에 관해 나와 있다.

그림 2. vmstat –I 1 명령에서 나오는 출력
Output of the vmstat -I 1 command

각 열에 관한 설명에 관해선 밑에 나와 있는 표 4를 보면 된다.

표 4. 각 열에 관한 설명

칼럼	설명
kthr	샘플링구간에서 매초 당 커널 쓰레드 상태 변화량.
r	실행 큐에 위치한 커널 쓰레드 수.
b	가상 메모리 관리자 (VMM) 대기 큐 (대기 리소스, 대기 I/O)에 위치한 커널 쓰레드 수.
p	미가공 I/O 시스템 종료 시 대기하는(저널 파일 시스템(JFS)을 우회하는) 쓰레드 수, AIX 5을 포함한 최신 버전에만 적용된다.
fi/fo	매 초당 페이지 인/아웃되는 파일 페이지수. 주: 이 열은 AIX 5을 포함한 최신 시스템에서만 적용된다.
cpu	CPU 시간의 사용장애율(%). 멀티프로세서 시스템의 경우 CPU 값은 모든 프로세서에 관해 평균한 값이 된다. 또한 I/O 대기 상태는 프로세서 당이 아닌 시스템 수준으로 정의된다.
us	사용자 모드에서 실행되는 CPU 시간 평균 백분율.
sy	시스템 모드에서 실행되는 CPU 시간 평균 백분율.
id	CPU가 유휴되고 시스템에 현저한 디스크 I/O 요구가 없는 시간 평균비율
wa	시스템에서 현저한 디스크/NFS I/O 요구가 있었던 시간 동안의 CPU 유휴시간. 대기작동 중 디스크에 적어도 하나 이상의 현저한 I/O 요구가 있는 경우 CPU 기간은 I/O 대기로 분류된다. 비동기화 I/O가 이 과정에 의해 활용되지 않는 한 디스크에 대한 I/O 요구로 인해 호출 과정이 요구 종료 시까지 방해된다. 프로세스에 관한 I/O 요구가 종료되면 그 요구는 실행 큐로 가게 된다. I/O 요구가 더 빨리 종료되는 경우엔 더 많은 CPU 시간이 들게 된다.
pc	사용된 물리적 프로세서 개수. 공유프로세서로 파티션이 작동될 경우에만 나타나는 매개변수.
ec	사용된 인타이틀 용량 백분율. 공유프로세서로 파티션이 작동될 경우에만 나타나는 매개변수.

여기서 CPU가 유휴 상태이고 현저한 I/O 요구가 CPU에서 초기화되는 경우 클럭 인터럽트 발생 시 (매 1/100ms마다) CPU에선 wio라고 표시된다. CPU에서 현저한 I/O 요구가 없는 상태에서 유휴상태에 있는 경우 CPU에선 wa 대신 id로 표시된다. 예를 들어, I/O 요구를 수행하는 네 개의 CPU 및 쓰레드 하나가 있는 시스템에서는 최대 25%의 wio 시간이 기록된다. I/O 요구를 수행하는 12개의 CPU 및 쓰레드 하나가 있는 시스템에서는 최대 8.3%의 wio 시간이 기록된다. 정확을 기하기 위해, wio에서는 I/O 요구가 종료되는 데 있어 CPU에서 대기 시 CPU 유휴상태 시의 시간 백분율을 측정한다.

이와 같은 4개의 열에서 백분율 합은 100%이거나 100%에 근접한 값이어야 한다. 여기서 사용자 시스템 (us및 sy) CPU-초기화 백분율이 일정하게 100%에 근접한 경우 시스템에서는 CPU 병목현상이 발생할 수도 있다

iostat

시스템 I/O 장치를 모니터하는 데 주로 iostat 명령을 사용한다. 이 명령은 또한 CPU 활용 데이터를 제공하기도 한다. AIX 5.3에서 iostat 명령이 시작되는 경우 이 명령을 통해 Micro-Partitioning 및 SMT 환경에서 사용되는 물리적 프로세서 수(physc) 및 사용된 인타이틀먼트 비율(% entc)이 기록된다. 이와 같은 측정 기준들은 Micro-partitioning 및 SMT 기준에서만 나타난다. SMT 기준을 설정한 경우 iostat명령은 자동적으로

%user
%sys
%wait
%idle

에 관한 새로운 PURR-기반 데이터 및 포뮬라를 사용한다.

다음과 같이 "iostat 5 3"을 입력하면서 AIX 5L Version 5.3 system 상에서 Listing 6이 만들어진다.

Listing 6. iostat 리포트

System configuration: lcpu=4 drives=9tty: tin tout avq-cpu: %user %sys %idle %iowait     0.0 4.3        0.2   0.6  98.8   0.4Disks: %tm_act Kbps tps      Kb_read Kb_wrtnhdisk0   0.0   0.2  0.0       7993    4408hdisk1   0.0   0.0  0.0       2179    1692hdisk2   0.4   1.5  0.3      67548   59151cd0      0.0   0.0  0.0          0       0tty: tin tout cpu: %user %sys %idle %iowait     0.0 30.3       8.8   7.2  83.9    0.2Disks: %tm_act Kbps tps      Kb_read Kb_wrtnhdisk0   0.2   0.8  0.2          4       0hdisk1   0.0   0.0  0.0          0       0hdisk2   0.0   0.0  0.0          0       0cd0      0.0   0.0  0.0          0       0tty: tin tout cpu: %user %sys %idle %iowait     0.0 8.4        0.2   5.8   0.0   93.8Disks: %tm_act Kbps tps      Kb_read Kb_wrtnhdisk0   0.0   0.0  0.0          0       0hdisk1   0.0   0.0  0.0          0       0hdisk2  98.4  75.6 61.9        396    2488cd0      0.0   0.0  0.0          0       0Example iostat with SPLAR configuration#iostat –t 2 3System Configuration: lcpu=4 ent=0.80avg-cpu   %user   %sys    %idle     %iowait   physc     %entc           0.1     0.2     99.7       0.0      0.0       0.9           0.1     0.4     99.5       0.0      0.0       1.1           0.1     0.2     99.7       0.0      0.0       0.9

vmstat 명령 리포트의 경우와 마찬가지로 첫번째 리포트에서는 시스템 작동개시 이후의 평균 통계량이 포함되어 있다. 연이어 이어지는 리포트에서는 첫번째 리포트 이후 1초 동안 수집된 통계량들이 포함되어 있다.

CPU 사용장애시간을 나타내는 4개의 열은 vmstat 명령의 경우와 같은 정보를 전달한다. 이 열들의 백분율 합은 반드시 100%에 가까워야 한다. 사용자 및 시스템(us 및 sy) CPU 활용 백분율 합이 100%에 가까워질 경우 시스템에서는 CPU 병목현상이 나타날 수도 있다.

한 애플리케이션을 수행하는 시스템의 경우 높은 I/O 요구비율은 워크로드와 연관될 수 있다. 많은 프로세스가 있는 시스템의 경우, 작동되는 시스템이 있는가 하면 I/O 대기 중인 시스템도 있다. 이 경우 작동 프로세스에서 대기시간 일부를 "숨기기(hide)" 때문에 %iowait 값이 극소수의 값이거나 0이 될 수 있다. %iostat값이 작은 경우 CPU 병목현상으로 인해 애플리케이션 성능에 제약이 생길 수 있다. iostat 명령을 통해 연산위주의 상황이 존재하지 않고 %iowait의 값이 20% 이상인 경우 I/O 요구 또는 디스크 위주 상황이 나올 수도 있다.

sar

sar 명령엔 두 가지 형식이 있다. 먼저 시스템 통계량을 샘플링하고 나타내거나 저장하는 형식이 있고 이전에 얻은 데이터를 처리하고 나타내는 두 번째 형식이 있다. sar 명령은 vmstat 및 iostat 명령의 경우에서와 같이 큐 및 프로세서 통계량을 제공한다. 하지만 sar 명령에서는 두 가지 특징이 더 나타난다.

각 샘플마다 주요 타임 스탬프가 있어 전체 통계량 평균은 샘플 맨 끝에 나타난다.
모든 프로세서에 대한 전체 평균에 더하여 프로세서 당 통계량을 생성시키는 데 있어 -P 옵션을 사용한다. 밑에 나타낸 샘플 코드는 두 가지 명령을 입력하면서 나타나는 4-way 대칭 멀티프로세서(SMP) 시스템에서 나오게 되는 샘플 출력을 나타낸다.
- sar -o savefile 5 3 > /dev/null &
  주: 이 명령은 5초 간격으로 데이터를 세 번씩 모으고 savefile에 수집된 데이터를 저장한 다음 리포트를 여백 상태로 만든다. 그렇게 되면 단말기에 리포트가 전혀 기록되지 않는다.
- sar -P ALL -u -f savefile
  주: -P ALL을 지정해 각각의 프로세서에 관한 프로세서 당 통계량 및 -u CPU 사용 데이터를 얻는다. 또한 -f savefile 명령으로 sar 명령에서 savefile에 저장된 데이터를 이용해 리포트를 형성시킨다. SMT가 설정된 상태에서 모든 논리적 프로세서에 관한 sar –P All 출력을 통해 사용된 물리적 프로세서 physc(델타 PURR/델타 TB)에 관한 정보를 알게 된다. 이 열은 프로세서 간에 분리된 상대적 SMT, 즉 논리적 프로세서에서 물리적 프로세서 사이클을 얻는데 걸리는 시간의 측정값을 나타낸다. 인타이틀된 사용용량 백분율이 100% 이하인 경우 U로 시작되는 라인이 추가돼 사용되지 않은 용량을 나타낸다. 공유모드에서 sar 명령을 수행할 시 이 명령에서는 (PPC/ENT)*100의 공식으로 나타내는 사용된 인타이틀먼트 퍼센티지(%entc)를 나타낸다.

Listing 7. 전용 LPAR 구성의 투웨이 p520 시스템에서 나오는 전형적인 sar 명령으로 인한 리포트

AIX nutmeg 3 5 00CD241F4C00    06/14/05 System configuration: lcpu=4 11:51:33 cpu    %usr    %sys    %wio   %idle   physc11:51:34  0        0       0       0     100    0.30          1        1       1       1      98    0.69          2        2       1       0      96    0.69          3        0       0       0     100    0.31          -        1       1       0      98    1.9911:51:35  0        0       0       0     100    0.31          1        0       0       0     100    0.69          2        0       0       0     100    0.73          3        0       0       0     100    0.31          -        0       0       0     100    2.0411:51:36  0        0       0       0     100    0.31          1        0       0       0     100    0.69          2        0       0       0     100    0.70          3        0       0       0     100    0.31          -        0       0       0     100    2.0111:51:37  0        0       0       0     100    0.31          1        0       0       0     100    0.69          2        0       0       0     100    0.69          3        0       0       0     100    0.31          -        0       0       0     100    2.00 Average   0        0       0       0     100    0.31          1        0       0       0      99    0.69          2        1       0       0      99    0.70          3        0       0       0     100    0.31          -        0       0       0      99    2.01

mpstat

mpstat 명령에서는 시스템에서의 모든 논리 CPU에 관한 성능관련 통계량을 모으고 나타낸다. SMT 설정의 경우 mpstat –s 명령을 통해 Listing 8에 나타나 있듯이 논리적 프로세서 용도뿐만 아니라 프로세서 유형까지 나타나게 된다.

Listing 8. SPLAR 구성을 하고 있는 투웨이 p520 시스템에서 나오는 전형적 mpstat 명령에서의 리포트

System configuration: lcpu=4 Proc0           Proc163.65%          63.65% cpu2    cpu0    cpu1    cpu358.15%   5.50%  61.43%   2.22%

lparstat

lparstat 명령에서는 LPAR-관련 정보 및 LPAR-활용 통계량에 관한 리포트를 제공한다. 이 명령을 통해 LPAR에 관한 활용 통계량 및 LPAR 관련 매개변수, 그리고 하이퍼바이저 정보까지 알 수 있게 된다. 구간 메커니즘으로 일정 시간 동안의 여러 리포트를 검색한다.

다음의 통계량은 파티션 형식이 공유된 형식에서만 나타난다.

physc	사용된 물리적 프로세서 개수를 나타냄.
%entc	인타이틀먼트 용량비율을 나타냄.
lbusy	사용자 및 시스템 레벨에서 수행하는 동안 발생한 논리적 프로세서 활용비율을 나타냄.
app	공유 풀에서의 사용 가능한 물리적 프로세서를 나타냄.
phint	수신된 팬텀 인터럽션 회수(이 풀에서 공유된 또 하나의 파티션에 맞추어진 팬텀)를 나타냄.

한편 -h 플래그가 지정된 경우에만 다음의 통계량이 나타난다.

%hypv	하이퍼바이저(hypervisor)에서 보낸 시간을 나타냄.
hcalls	하이퍼바이저(hypervisor) 호출 수행개수를 나타냄

Listing 9. 투웨이 p520 머신에서 나오는 전형적 Iparstat 리포트

System configuration: type=Dedicated mode=Capped smt=On lcpu=4 mem=15808 %user  %sys  %wait  %idle-----  ----  -----  -----  0.0   0.1    0.0   99.9  0.0   0.1    0.0   99.9  0.4   0.2    0.1   99.3 # lparstat 1 3 System configuration: type=Shared mode=Uncapped smt=On lcpu=2 mem=2560 ent=0.50 %user  %sys  %wait  %idle physc %entc  lbusy   app  vcsw phint-----  ----  -----  ----- ----- ----- ------   ---  ---- -----  0.3   0.4    0.0   99.3  0.01   1.1    0.0     -   346     0 43.2   6.9    0.0   49.9  0.29  58.4   12.7     -   389     0  0.1   0.4    0.0   99.5  0.00   0.9    0.0     -   312     0

위로

시스템 성능향상

연산위주의 시스템에서 쓰레드 및 특수 프로세스의 프로세스 우선순위를 처리하거나 스케줄러 알고리즘을 조정해 시스템 성능을 향상시켜 여러 가지 다른 시스템 수준의 스케줄링 정책을 설정한다.

사용자-프로세스 우선순위 변경

사용자 태스크 우선순위를 변경 또는 설정하는 명령은 API 호출을 통해 쓰레드 우선순위 및 스케줄링 정책을 변경하는 nice, renice 명령 및 두 개의 시스템 명령 등이 포함되어 있다.

nice 명령 사용

프로세스가 ksh 또는 csh에서 시작되는 경우 (tcsh 및 bsh에서 시작되는 경우에는 20) 자료구조 전면 프로세스 및 백그라운드 프로세스의 표준 nice 값은 각각 20, 24다. 시스템에서는 nice 값을 사용해 이 프로세스와 관련된 모든 쓰레드의 우선순위를 계산한다. 사용자는 nice 명령을 사용해 표준 nice 값에 대한 증가치, 감소치를 지정, 우선순위가 이전과 다른 상태에서 프로세스를 시작하게 된다. 여기서 쓰레드 우선순위는 여전히 변할 수 있고 쓰레드의 CPU 사용에 근거해 여러 가지 다른 값을 갖게 된다.

어떤 사용자라도 nice 명령을 이용해 보통레벨보다 낮은 우선순위의 명령을 실행시킨다. 한편 종합관리자만 nice 명령을 이용, 보통레벨보다 높은 우선순위의 명령을 실행시킨다. 예를 들어, nice -5 iostat 10 3 >iostat.out 명령을 통해 iostat 명령은 nice 값이 25(20대신)인 상태에서 시작되어 이 명령과 관련된 시작 우선순위가 낮아지게 된다.-l 플래그가 있는 ps 명령을 사용, nice 및 우선순위 값을 보게 된다. Listing 10에서는 ps -l 명령을 이용해 나타낸 전형적인 출력상태에 관해 수록되어 있다.

Listing 10. 프로세스 ps –I를 이용, 프로세스 우선순위가 나타난 화면

       F S UID   PID  PPID   C PRI NI ADDR    SZ    WCHAN    TTY  TIME CMD  240001 A   0 15396  5746   1  60 20 393ce   732           pts/3  0:00 ksh  200001 A   0 15810 15396   3  70 25 793fe   524           pts/3  0:00 iostat

종합관리자인 여러분은 # nice --5 vmstat 10 3 >io.out 명령으로 더 높은 우선순위에 있는 명령을 실행시킨다. nice 값이 15인 상태에서 iostat 명령을 실행시키면 더 높은 시작 우선순위의 명령이 나오게 된다.

renice 명령 사용

프로세스가 이미 작동 중인 경우 renice 명령을 이용, nice 값 및 명령 우선순위를 변경시킨다. 프로세스 ID, 프로세스 그룹 ID, 또는 프로세스 소유 사용자 이름으로 프로세스를 규명한다. 고정 우선순위 프로세스엔 renice 명령을 사용할 수 없다.

setpri() 및 thread_setsched() 서브루틴 사용

사용자가 각각의 프로세스 또는 쓰레드를 만들어 우선순위를 고정시키게끔 하는 두 가지 시스템 호출명령이 있다. setpri() system 및 thread_setsched() 호출명령은 각각 프로세스 및 쓰레드 성향의 명령이다. 이 두 가지 서브루틴을 잘못 사용하면 시스템이 정지되기 때문에 서브루틴 사용 시 조심해야 한다.

전체사용자 ID하에서 작동하는 애플리케이션을 통해 setpri() 서브루틴에서 자체 우선순위 또는 또 다른 프로세스에 관한 우선순위를 설정하게 된다. 우선순위가 고정된 상태에서 SCHED_RR 스케줄링 정책을 이용해 원하는 프로세스를 만들게 되고 프로세스에 있는 모든 쓰레드에서 변화가 이루어지게 된다. 다음의 두 가지 예를 보자.

retcode = setpri(0, 45);

여기 호출 프로세스에서 고정 우선순위가 45로 정해져 있다.

retcode = setpri(1234, 35);

위의 호출 프로세스에서는 PID값이 1234이며 고정우선순위는 35로 주어져 있다.

여기서 특수 쓰레드를 변환시키고자 할 경우, 다음과 같은 thread_setsched() 서브루틴을 사용한다.

retcode = thread_setsched(thread_id,priority_value, scheduling_policy)

scheduling_policy 매개변수는 다음 값 중 하나로 설정한다.

SCHED_OTHER, SCHED_FIFO, or SCHED_RR.

scheduling_policy 매개변수 값으로 SCHED_OTHER를 지정하는 경우 두 번째 매개변수인 (priority_value)값은 무시된다.

일반적인 스케줄링 알고리즘 변환

AIX 스케줄러로 사용자는 schedo 명령을 이용해 우선순위 계산공식을 변환시킨다.

r 및 d 값 조정

이전에도 언급했듯이 우선순위 값을 계산하는 공식은 다음과 같다.

Priority = x_nice + (C * r/32 * x_nice_factor)

최근 CPU 사용값은 ps 명령출력에서 C 열로 나타난다. 최근 CPU 사용에 관한 최대값은 120이다. 매초마다 각 쓰레드에 관한 CPU 사용값은 다음의 공식을 이용, 변화된다.

New Charge C = (Old Charge C) * d / 32

여기서 r 의 기본값은 16이다. 따라서, 쓰레드 우선순위는 최근 CPU 사용률 * 0.5로 벌점변환된다. d의 기본값도 16인데 이는 모든 과정에서의 CPU 사용값이 매초마다 원 사용값의 반으로 줄어든다는 것을 의미한다. 한편 sched_R 및 sched_D의 기본값이 자료구조 전면 프로세스 및 후면 프로세스 간의 차이를 구분 짓는 데 충분치 않은 사용자도 있다. 이 때 sched_R 및 sched_D 옵션을 이용해 schedo 명령으로 상기 두 기본값을 조정한다. 다음의 두 가지 예를 주목한다.

# schedo -o sched_R=0
(R=0, D=.5)의 경우 이는 CPU 패널티가 항상 0임을 의미한다. 프로세스에 관한 우선순위 값은 효과적으로 고정되지만 이 경우 프로세스는 RR프로세스와 같이 처리되지는 않는다.
# schedo -o sched_D=32
(R=0.5, D=1)의 경우 이는 긴 시간의 작동 프로세스로 C값이 120으로 고정됨을 의미한다. 매초마다 현재 CPU 사용값은 더 이상 줄어들지 않으며 긴 시간의 작동 프로세스 우선순위가 낮아져(중요성이 더 높아짐) 새 프로세스로 대체되지는 않게 된다.

타임슬라이스 변경

schedo 명령으로 스케줄러 타임슬라이스 길이를 변경시키지만 이는 RR 쓰레드의 경우에만 적용된다. 이런 변경은 다른 스케줄링 정책으로 작동되는 쓰레드에 영향을 주지는 않는다. schedo 명령에 관한 문구는 다음과 같다.

schedo -L timeslice

여기서 n은 10ms 클럭 틱 횟수로 타임슬라이스 기능으로 사용된다. schedo -p -o timeslice=2 구문을 사용하면 타임슬라이스 길이는 20ms로 고정된다.

전체사용자인 여러분은 로그온해 schedo 명령을 사용하면서 타임슬라이스 변경기능을 쓴다.

위로

부가적 기술 사용

연산위주의 시스템에 도움이 되는 기타 기법들은 다음과 같다.

스케줄링

여러분은 애플리케이션의 상대적 중요성에 따라 at, cron, batch 명령을 사용해 off-shift 시간에 관해 그다지 중요하지 않은 애플리케이션을 스케줄링하기도 한다.

mkpasswd 명령 사용

여러분 시스템에 /etc/passwd 파일 엔트리가 수없이 많은 경우 mkpasswd 명령을 사용, /etc/passwd 파일의 해쉬/인덱스 버전을 만들어 사용자 ID를 탐색하는 데 소요되는 시간을 절약한다.

위로

애플리케이션 튜닝

다음과 같은 기법은 AIX 스케줄러 하에서 작동되는 특수 애플리케이션의 성능을 진단하고 향상시키는데 도움이 된다.

ps 명령사용

ps 명령 또는 프로파일링을 이용해 대부분의 CPU 시간을 소비하는 애플리케이션을 식별한다. 이와 같은 정보는 CPU 병목현상에 관한 탐색시간을 줄이기 위해 사용한다. 문제가 발생한 영역을 찾은 후 여러분은 애플리케이션을 조정하거나 기능을 향상시킬 수 있다. 여기서 애플리케이션을 재컴파일하거나 또는 소스코드를 변환하는 일이 필요할지도 모른다

schedo 명령사용

모든 CPU 스케줄러 조정 매개변수에 관한 현재 또는 다음 부트 값을 설정하거나 나타나는 데 schedo 명령을 사용한다. schedo 명령은 전체사용자만 실행할 수 있다. 이 명령으로 다음 재부팅 때까지 매개변수를 영구적으로 변환시키거나 변환을 늦출 수도 있다. AIX 5L Version 5.3에서 schedo 명령을 시작하면 이 명령에 몇 가지 조정매개변수가 추가된다. Listing 11에서는 모든 CPU 스케줄러 매개변수에 관해 나와 있다.

Listing 11. CPU 스케줄러 매개변수

# schedo -a              %usDelta = 100          affinity_lim = 7         big_tick_size = 1      fixed_pri_global = 0             force_grq = 0       hotlocks_enable = 0idle_migration_barrier = 4    krlock_confer2self = n/a  krlock_conferb4alloc = n/a         krlock_enable = n/a    krlock_spinb4alloc = n/a   krlock_spinb4confer = n/a               maxspin = 16384    n_idle_loop_vlopri = 100              pacefork = 10               sched_D = 16               sched_R = 16 search_globalrq_mload = 256  search_smtrunq_mload = 256  setnewrq_sidle_mload = 384   shed_primrunq_mload = 64    sidle_S1runq_mload = 64    sidle_S2runq_mload = 134    sidle_S3runq_mload = 134    sidle_S4runq_mload = 4294967040    slock_spinb4confer = 1024      smt_snooze_delay = 0     smtrunq_load_diff = 2             timeslice = 1        unboost_inflih = 1         v_exempt_secs = 2         v_min_process = 2           v_repage_hi = 0         v_repage_proc = 4            v_sec_wait = 1

업그레이드(Upgrading)

매개변수 조정을 해도 시스템 성능 향상이 이루어지지 않는 경우엔 시스템을 더 빠른 CPU로 또는 더 많은 CPU로 업그레이드시키는 일이 필요할 수도 있다.

위로

케이스 스터디(Case studies)

다음과 같이 실제 상황에서 발생하는 두 가지 예를 통해 IBM 시스템 성능전문가들이 이와 같은 이론 및 기법을 수행한 방식을 알게 된다..

사례 1

증상: 사용자는 기타 500개의 배치 스크립트를 시작하는 배치 스크립트를 소유하고 있고 스크립트 각각은 데이터베이스를 점검하면서 업데이트한다. 각각의 스크립트는 또한 다른 머신으로부터 나온 클라이언트 요구로 시작된다. 응답시간은 일정기간 동안 10초 이하에서 시작된다. 그러다 응답시간은 점점 길어져 1분을 넘을 때도 있고 심지어는 2분까지 가는 경우도 있다.

진단: 이런 경우 실행 큐가 커지기 시작하면서 어마어마한 양에 이르게 된다. 또한 CPU를 100% 활용하고 이 가운데 99%가 사용자 모드 상에 있는(이것이 8-WAY SMP 시스템이다.) 등의 증상 등이 생긴다. 수초동안 수집된 AIX 트레이스 샘플을 조사하면서 패턴출현을 관찰했다. 쓰레드에서 CPU를 사용하는 동안 네트워크 패킷이 CPU에 도달하면서 네트워크 어댑터 인터럽트 현상이 일어나게 된다. 이렇게 되면 현재 작동중인 쓰레드가 CPU에서 나가면서 인터럽트 현상이 없어지게 된다.

인터럽트 현상이 없어진 후 스케줄러에서는 기타 쓰레드가 작동가능하고 현재 작동중인 쓰레드보다 더 나은 우선순위를 지녔는지 그 여부를 검증하게 된다. 현재 작동중인 쓰레드는 이미 분할된 시간동안 작동되었기 때문에 쓰레드에서 CPU 틱을 축적할 때 쓰레드와 관련된 CPU 우선순위는 증가했던 것이다. 이 쓰레드와 관련된 500개의 스크립트 각각은 우선순위 60에서 시작되었다. 기타 쓰레드가 작동 가능한 경우 이 쓰레드는 우선순위 60보다 높은 쓰레드 우선순위를 가지고 현재 작동중인 쓰레드를 대신하게 된다. 그렇게 되면 대체된 기타 쓰레드는 실행 큐 끝에 있으면서 CPU 우선순위가 다시 증가할 때까지 CPU 대기상태에 있어야 한다.

이와 같은 대체효과로 인해 때로는 데이터베이스 잠금기능을 보유하고 있는 동안에 쓰레드가 대체된다. 이런 형식의 잠금기능이 데이터베이스 소프트웨어 내의 애플리케이션 층에서 실행되기 때문에 커널에서는 쓰레드에서 잠금기능을 보유하고 있는지 그 여부를 인식하지 못한다. 잠금기능이 커널수준의 잠금기능, 또는 pthread 라이브러리 뮤텍스 잠금기능인 경우 커널에서는 우선순위 증감기능을 수행하거나 또는 잠금기능이 요구되는 작동 쓰레드의 우선순위와 같은 수준의 쓰레드 우선순위를 증감시키게 된다. 이런 식으로 요구 쓰레드는 잠금 홀더에서 CPU를 다시 차지해 잠금기능을 해제하게끔 대기상태에서 오랫동안 있을 필요가 없다.

이런 경우의 잠금기능은 사용자 잠금기능이라 데이터베이스 쓰레드는 잠금기능상에서 돌게 되고 결국 쓰레드는 스핀 카운트(조정 가능한 데이터베이스 매개변수임)를 다 쓰게 된 뒤 휴면상태에 들어가게 된다. 따라서 대개 데이터베이스 잠금기능 상에서 도는 쓰레드로 인해 CPU의 99%가 사용되는 것이다.

솔루션: 우선순위 대체로 인해 부정적인 효과가 난다는 것을 알아낸 뒤 우리는 쓰레드 우선순위를 계산하는 데 사용되는 스케줄러 공식을 조정했다. 그 특수용도의 공식은 다음과 같다.

pri = base_pri + NICE + (C * r/32)

여기서 pri는 새로운 우선순위, base_pri값은 40, NICE는 nice 값(이 경우 20), C는 틱 당 CPU 사용도를 가리키며, r 값은 16이다.

쓰레드에서 CPU 틱을 축적하면서 쓰레드 우선순위 값은 증가하며 따라서 쓰레드 우선순위는 낮아지게 된다.

여기서 schedo 명령은 sched_R 옵션을 사용하면서 r 값을 변화시키는 방식을 제공한다. schedo -p -o sched_R=0 명령을 작동시키게 되면 r 값은 0이 되고 결국 CPU 패널티 인자(C*r/32)도 0이 된다. 이렇게 되면 nice값이 변하지 않는 한 우선순위가 변하지 않게 되면서 쓰레드는 우선순위 변화로 인해 대체되는 일이 없이 분할시간을 종료하게 된다. 결국엔 현재 데이터베이스 잠금기능을 작동시키면서 보유하고 있는 쓰레드가 계속 작동되면서 잠금기능이 해제된다.

결과: 이런 변화로 인해 시스템 성능에 즉각적인 영향을 미친다. 이 경우 2분 이상인 응답시간은 점점 줄어들기 시작하면서 모든 스크립트가 몇 초안으로 종료된다. CPU 사용 소멸인자 (C = C*d/32)를 이용하면서 우선순위 공식에서의 C값은 매초마다 다시 재계산된다. schedo 명령을 사용할 시 d값을 0으로 설정할 경우 같은 결과가 나오게 된다. 이 경우 d=0이면 C*d/32의 값은 0이 된다. CPU 패널티 인자는 C*r/32이므로 이마저도 0이 되면서 결국 우선순위는 40 + NICE 값이 된다.

C사례 2

증상: 데이터 및 애플리케이션 서버용으로 pSeries 머신을 사용한다. 사용자들은 요구사항들을 형식 기반 애플리케이션에 입력해 이를 트랜잭션에 전송한다. 이들은 어느 순간 화면 상에서 형식 업데이트 시 또는 단기간 실행 큐에 있어 시간이 더 오래 걸린다는 사실을 인식했다.

진단: 작업처리시간이 오래 걸리고 여기에 긴 시간 동안 작동되는 배치작업이 시스템에 전송되면서 그 시간은 더 길어지게 된다. 보통, 그와 같은 배치작업은 밤에 작동되지만 월말 무렵 사용자가 시스템 상에 있는 동안 부가적인 배치작업은 낮 동안 작동되기도 한다. 이같이 배치작업은 연산위주의 성향을 지니며 계속 실행 큐상에 있게 된다. 따라서 사용자 쓰레드는 CPU용 배치작업 쓰레드에 필적해야 한다.

CPU 사용률이 늘어남에 따라 우선순위가 줄어들면서 배치작업 우선순위는 낮아지게 되며 사용자 쓰레드는 작동하게 된다. 하지만 CPU 사용값 C가 매 초당 반으로 줄어들면서 커널 또한 줄어들게 된다. 이렇게 되면 배치작업 우선순위는 짧은 시간 동안 향상되게 된다. 따라서 배치작업은 사용자 쓰레드가 있는 CPU에 필적하게 된다.

솔루션: 1초당 CPU 사용률을 줄이는 데 사용되는 소멸인자(d/32)를 변화시킴으로써 사용자에 관한 시스템 성능을 향상시켰다. 우리는 schedo 명령을 사용해 d 값을 31로 설정했다. d 값이 높을수록 C (C=C*d/32)도 높아진다.

우선순위(pri=40+NICE+C*r/32)를 계산하는 데 C 값을 사용하므로, C 값이 커질수록 우선순위는 낮아지게 된다. d값을 더 높게 설정할수록 C 값은 보통 때보다 더 느리게 감소한다.

결과: 사용자 쓰레드는 배치 쓰레드보다 CPU 공간을 종종 더 차지한다. 그 결과 사용자는 시스템 성능에 있어 즉각적으로 향상되는 것을 목격했다. 물론 배치작업 속도도 어느 정도 늦춰졌지만 사용자에게 "일고(think)" 시간이 있거나 또는 사용자가 I/O 대기상태에 있어야만 하는 경우마다, 배치작업은 CPU를 차지하게 된다. 배치작업 상에서 이와 같은 영향은 최소화되지만 사용자를 위한 성능향상은 몰라보게 향상되었다.

사례연구 주: 패턴 추적

마지막 내용에서는 시스템 성능에 영향을 끼치는 몇 가지 기이한 사항들에 대해 나와 있다. 벤치마크 작업 동안 우리는 CPU 사용률이 100%에 도달했고 이 가운데 대부분은 "시스템(system)"에 할당되었음을 인식했다. 그 때 애플리케이션 성능은 상당부분 감소했다.

우리는 AIX 트레이스를 수집한 뒤 이에 따르는 반복적 패턴을 알아냈다. 한 애플리케이션 프로세스에서 어드레스 상에 페이지 오류가 발생했는데 이 오류는 가상 메모리 머신(VMM)에 보호예외기능을 발생시키고 이로 인해 커널에서는 이 프로세스에 SIGSEGV(지역침입) 신호를 전송한다. 이와 같은 프로세스가 계속될 때 같은 어드레스 상에 페이지 오류가 계속 발생되면서 또 다른 보호예외기능이 발생, 또 다른 SIGSEGV(지역침입)신호를 상기 프로세스에 전송한다. SIGSEGV(지역침입) 신호에 기본신호를 축적함으로써 프로세스를 죽이게 되고 결국엔 코어 덤프현상이 발생하게 된다. 하지만 이 경우 애플리케이션은 이와 같은 루프 상에서 계속 진행되었다. 대부분의 CPU 시간은 이 루프에서 사용되었던 것이다.

사례 연구 후에 다음과 같은 문제를 발견했다. 또 다른 컴포넌트 개발자는 신호 핸들러를 설치해 테스트 프로세스 동안 코드 내의 SIGSEGV(지역침입) 신호를 잡아냈다. 테스트 종료 후, 개발자는 신호 핸들러를 제거해야 한다는 사실을 잊어버렸다. 신호 핸들러는 나머지 애플리케이션과 연관 있었고 애플리케이션과 관련 없는 또 다른 신호 핸들러로 지역침입신호가 발생했다. 이와 같은 구식 신호 핸들러로 보호예외기능을 포착하면서 이 기능이 무시되었고 프로세스는 계속 진행되었다. 그러면서 현 명령(보호예외기능을 발생시키는 명령)이 다시 재 시작되고 무한대의 루프가 발생되었다.

참고자료

필자소개


		Wayne Huang, 컨설턴트, IBM


		Lee Cheng, 컨설턴트, IBM


		Matthew Accapadi, 소프트웨어 엔지니어, IBM


		Nam Keung, 프로그래머, IBM